@minhyuc

Analyzing the iOS Local Network Permission from a Technical and User Perspective

48 min read

Abstract

  • 로컬 네트워크 액세스로부터 보안과 프라이버시 문제를 완화시키기 위해 애플은 새로운 permission을 도입한 iOS 14를 출시하였다.
  • 4가지 양상 연구를 통해 로컬 네트워크 Permission에 대한 종합 분석을 실시한다.
    • 시스템적으로 로컬 네트워크에 액세스하는 보안 측면에서의 구현을 조사한다.
    • 10,862 개의 iOS, Android 앱을 대상으로 대규모의 동적 분석을 통해 로컬 네트워크 액세스에 대해 탐색한다.
    • 사용자가 결정을 내리기 전에 정보를 얻는 프로세스인 permission 프롬프트를 구성하는 개념에 대해 분석한다.
    • 식별된 개념에 대해 온라인 조사(N = 150)를 실시한다. 이를 통해 사용자의 permission에 대한 이해도와 위협에 대한 인식, 일반적인 오해를 파악한다.

1. Introduction

  • 앱이 로컬 네트워크에 액세스 할 수 있다면 새로운 공격 벡터를 열며 디바이스와도 통신할 수 있다.
    • 따라서 개인의 로컬 네트워크의 정보를 수집하는 것은 추적 및 사용자 프로파일링을 할 수 있도록 한다.
  • 로컬 네트워크 permissions 구현에 대한 주제는 이전에 이미 연구되었다.
    • Youtube가 로컬 네트워크 permission을 우회한다는 사용자들의 우려도 있었다.
      • 이는 애플의 AirPlay 기능을 사용함에 있어서 야기된 것인데, 이 기능은 permission을 요구하지 않는다.
    • 하지만 허가되지 않은 액세스는 가능하고, 더 나아가 로컬 네트워크 액세스가 얼마나 널리 퍼져 있는지, 그리고 충분한 permission이 없어 앱이 안드로이드에서는 다르게 행동하는 케이스가 불분명하다.
  • 위와 같은 간극을 채우기 위해서, 이 논문에서는 기술과 사용자 관점 두 가지의 학술적인 접근방식을 사용하는 것을 제안한다.
    • 포괄적 평가
      • 기능의 보안과 프라이버시
      • 앱이 로컬 네트워크에 액세스하는 법
      • 앱이 사용자를 유도하는 법
      • permisson에 대한 사용자의 이해
  • permission이 보안상 안전하게 설계되어 있지 않는다면 보안과 프라이버시에 있어 false sense가 존재할 수 있다.
  • 마찬다지로, 사용자가 정보에 입각한 결정을 내리지 못 한다면, 악성 앱들은 사용자들이 권한을 부여하도록 이끈다.

Figure 1

  • RQ1: Is the local network permission implemented securely?
    • permission 구현이 안전한지, 혹은 우회가 가능한지.
    • 로컬 네트워크에 시스템적으로 액세스하여 잠재적인 간극을 찾는다.
  • RQ2: How prevalent is local network access in apps?
    • 앱에서의 로컬 네트워크 액세스가 얼마나 많이 퍼져 있는지, iOS와 안드로이드 두 운영체제에서 가용한 앱들을 실행함으로써 모니터링하는 대규모 분석 실행.
    • 10,862개 앱을 동적 분석
  • RQ3: Which concepts constitute the permission prompts?
    • permission 프롬프트의 정보를 조사.
    • 이는 개발자들이 액세스가 요청되는 이유를 설명하는 이론적 근거를 제공하는 현주소이다.
  • RQ4: What is the user’s understanding of these concepts?
    • 150명 대상의 온라인 사용자 설문조사: 로컬 네트워크 permission과 이를 통한 위협에 대한 사용자의 인식을 이해하기 위함
  • Contributions:
    • permission을 우회하는 2가지 방법 증명 및 permission의 보호된 로컬 주소의 범위가 불충분함
    • 10,862개 cross-platform 앱 분석: 152 iOS, 117 안드로이드 앱이 로컬 네트워크의 액세스 및 양 플랫폼 간의 차이점을 보여줌
    • permission 프롬프트 내의 reoccurring concepts를 식별 및 개발자에게 명시된 목적에 대한 통찰력을 제시
    • 거의 모든 참가자(83.11%)가 적어도 한 가지 이상의 위협에 대해 인식하고 있지만, 오해 또한 널리 퍼져 있다(84.46%).

2. Background & Motivation

  • 로컬 네트워크란
  • 로컬 네트워크에 액세스하는 앱에 의한 위협
  • 로컬 네트워크 액세스를 보호하는 iOS permission

2.1. Local Network

  • Accessible Devices
    • 네트워크의 서브넷 마스크에 연결된 IP 주소를 가진 기기
    • 네트워크 셋업에 따라 서브넷 마스크 밖의 IP 주소를 가진 기기도 접근 가능하다.
    • 서브넷 마스크 내부 기기를 위협한다면 외부 기기까지 도달할 수 있다는 것을 염두해 두어야 한다.
  • Virtual Private Networks (VPNs)
    • 기술적으로 VPN은 로컬 네트워크가 아니지만, 보안과 프라이버시 위협은 VPN 내부 기기까지도 영향을 미칠 수 있다.
    • 전형적으로, 로컬 네트워크와 VPN 내부 기기들은 인터넷에서 도달할 수 없다.
    • 하지만 이는 여전치 네트워크 내부의 다른 기기들에서 액세스 가능하다.

2.2. Threat Model

  • Security: 방화벽으로 인해 인터넷에서 로컬 네트워크에 연결된 기기는 직접적인 액세스가 어렵지만 로컬 네트워크 내에서는 접근 가능하기 때문에 내부 악성 앱들은 공격을 시도할 수 있고, 이는 IoT에서 또한 악성코드 감염와 탈취 문제를 야기한다.
  • Location: 앱은 라우터의 MAC 주소를 통해 온라인 DB의 위치 정보를 찾는다(과거에는 location permission을 우회하기 위해 사용).
  • Advertisements: 광고사들은 로컬 네트워크 내의 기기들에 기반하여 어떤 광고를 보여줄 지 결정한다(AliExpress가 이 때문에 user들의 불만을 야기함). Cross-device와 Cross-user 트래킹은 동일한 네트워크에 연결된 각기 다른 기기에서 통합되기 때문에 로컬 네트워크 정보가 사용자를 연결 하는 데에 사용되며, 사용자가 실제 이름으로 기기명을 설정할 경우 또한 매우 민감하다.
  • Misconceptions: 로컬 네트워크와 보안, 프라이버시 영향에 관한 대중의 이해가 부족하다(e.g., 의회 청문회에서 TikTok CEO가 받았던 질문). 이는 악성 앱들이 사용자를 속여 permission을 허용하도록 유도하며 속일 수 있다.

2.3. Permission Overview

  • 안드로이드는 앱이 permission을 통해 특정 데이터에 접근하거나 액션을 취하는 것을 제한한다.

  • 다음은 두 가지 주류 permission이다:

    1. Install-time permissions
    2. Runtime permissions

  • iOS 또한 앱이 추가 기능을 얻기 위해서를 자격(entitlements)을 선언하고, 사용자의 동의를 받는다.

    • 사용자 동의를 요청하고, 그 결정을 지속적으로 추적하기 위해 TCC 프레임워크가 필요하다; Transparency, Consent, Control.

  • Local Network Permission on iOS

    • 애플에 따르면, local network, multicast, broadcast 주소로 발신하는 모든 트래픽은 로컬 네트워크 permission을 요청한다.
    • 애플은 multicast와 broadcast 수신 트래픽까지 permission을 확장할 계획이지만, 현재 iOS 18에서는 적용되지 않았다.

  • permission 적용의 예외는 AirPlay와 프린트를 위한 OS에 의해 제공되는 Bonjour 서비스이다.

    • Bonjour는 로컬 네트워크 상에서의 디바이스와 서비스를 찾도록 허용하는 zero-configuration 프로토콜이다.
    • 애플은 이 방법이 앱에 네트워크 세부사항을 밝히지 않는다고 주장한다. 따라서 이 기능은 permission을 요구하지 않는다.
    • e.g., AirPlay: iOS 미디어 플레이어와 웹뷰는 비디오 재생 시에 요청을 보낸다. 하지만 로컬 네트워크 정보다 앱에 제공되지 않으므로 permission을 트리거하지 않는다.

  • 로컬 네트워크 permission을 요청하는 과정은 다른 iOS permission과는 다르다.

    • 앱 개발자는 permission을 직접 요청할 수 없고, 앱이 로컬 네트워크에 접근하고자 할 때에 OS가 사용자에게 permission을 부여하도록 요청한다.
    • 사용자에게 앱이 로컬 네트워크 permission을 요청한다는 것을 납득시키기 위해, 앱 개발자들은 permission request에 설명을 추가한다.
      • 설명이 없다면, iOS는 사용자에게 경고 메시지를 띄움.

3. Permission Implementation

  • 첫번째로, 연구에서는 iOS가 언제 로컬 네트워크 permission을 실행하는지 테스트하고 RQ1에 대한 해답을 찾는다: Is the local network permission implemented securely?
  • 시스템적으로 다른 주소에 대한 접근을 시도한다.

3.1. Methodology

  • 자체 테스트 앱 개발
    • 서로 다른 broadcast, local network, multicast 주소에 대한 접근을 시도한다.
    • palera1n 으로 jailbreak한(시스템의 보안을 우회한) iOS 16 iPhone 8에 테스트 앱을 설치했다.
    • 트래픽을 캡쳐하기 위해 tcpdump를 사용했다.
    • iPhone을 VPN에 연결하여 동일한 보안 위협이 적용되는 VPN 주소 공간의 보호를 테스트한다.
    • jailbreak가 연구에서 밝혀낸 결과에 영향을 주지 않았음을 확인하고, 위협이 이후의 버전에도 여전히 존재한다는 것을 증명하기 위해 jailbreak이 적용되지 않은 iOS 17.3 iPhone SE 2020에서 수동으로 이중 테스트를 진행했다.
  • 다양한 네트워크 API 및 프로토콜 테스트
    • 네트워크 접근 권한이 모든 경우에 일관적으로 적용되는지 확인하기 위해, 애플의 공식 developer documentation을 기반으로 16가지의 서로 다른 네트어크 API를 사용했다.
    • 공식적으로 언급된 TCP, UDP 외에도 인터넷 계층의 ICMP와 다른 전송 계층 프로토콜인 QUIC까지 포함하여 테스트의 범위를 넓혔다.
  • 실험 절차
    • 각 테스트 케이스를 명확히 식별하기 위해 테스트 전후로 제어 가능한 서버에 특정 ID를 포함한 GET 요청을 보냈다.
    • 모든 테스트 2번 씩 수행
      • 권한을 허용했을 때: 앱이 실제로 네트워크 요청을 보내는지 확인 (Positive Control)
      • 권한을 거부했을 때: iOS가 해당 요청을 제대로 차단하는지 확인 (Core Test)

3.2 Results

Table 1

3.2.1. Permission Bypass

  • 두 가지 Webview 컴포넌트를 사용할 때 로컬 네트워크 접근 권한을 요청하지 않고도 네트워크에 접근할 수 있는 우회 취약점을 발견했다.
  • SFSafariViewController: 앱 내에서 Safari 창처럼 외부 웹사이트를 보여주는 기능. 이 창에 로드된 웹사이트가 사용자 허락 없이 로컬 네트워크를 스캔하거나 공격할 수 있다.
  • WKWebView: 앱에 웹 콘텐츠를 직접 삽입하는 최신 기술
    • 문제점: 오히려 구형인 UIWebView는 안전했지만, 애플이 권장하는 최신 WKWebView에서 취약점이 발견되었다. 이는 “모든 트래픽에 권한이 필요하다”는 애플에 공식 설명과 정면으로 배치된다.
    • Case Study: Chrome, Firefox, Safari 등 대부분의 iOS용 서드파티 브라우저가 WKWebView를 사용하기 때문에, 이 브라우저들로 로컬 장치(e.g., 공유기 설정 페이지)에 접속하면 사용자에게 아무런 권한 요청 없이 해당 페이지가 로드된다.

Figure 2

3.2.2. Insufficient Protection

  • permission이 보호하는 네트워크의 범위가 너무 좁아서 발생하는 문제이다.
  • 복잡한 네트워크 주고: permission에 대한 보호가 현재 연결된 Wi-Fi의 서브넷 마스크 내로 한정된다.
    • e.g., 192.168.1.x 네트워크에 연결된 상태에서, 라우터를 통해 접근 가능한 다른 로컬 네트워크 대역(192.168.0.x)에는 권한 없이 접근이 가능.
    • VPN 환경: VPN을 통해 연결된 사설 네트워크 공간 역시 전혀 보호받지 못한다. 앱은 VPN 네트워크 내의 다른 장치들을 마음대로 스캔하고 통신할 수 있다.

3.2.3. Local Network Rationales

  • 앱이 로컬 네트워크 접근 권한을 요청할 때, 왜 그 권한이 필요한지에 대한 설명(Rationale)을 명시하지 않아도 permission 획득이 가능하다.
    • 문제점: 다른 민감한 권한(위치, 카메라 등)은 사용자가 합리적인 결정을 내릴 수 있도록 요청 사유를 반드시 명시해야 하지만, 로컬 네트워크 권한은 이 규칙이 적용되지 않는다. 이는 사용자가 정보 없이 권한을 허용하게 만들 수 있는 문제이다.

3.2.4. Responsible Disclosure

  • 웹뷰 우회 및 네트워크 보호 범위 문제: 2022년 6월에 애플에 report 했고, 애플은 수정을 위해 노력 중이라고 답변했지만, 2024년 10월까지 해결책이 나오지 않았다.
  • VPN 문제: 애플은 이를 보안 취약점이 아닌 예상된 동작 이라 분류하며 연구자들의 의견에 동의하지 않았다.

4. Permission Prevalence

  • 실제 앱들이 로컬 네트워크를 얼마나, 어떻게 사용하는지 분석하여 iOS의 권한 정책이 어떤 영향을 미치는지 보여준다.

4.1. Dataset

  • 연구의 신뢰도를 높이기 위해 iOS와 Android 동시 출시된 10,862개의 앱 쌍을 분석 대상으로 선정
  • 인기 앱과 무작위로 추출된 앱을 모두 포함하여 실제 사용 환경을 폭넓게 반영

4.2 Methodology

  • Dynamic Analysis 를 핵심 방법론으로 채택. iOS와 Android 앱의 로컬 네트워크 접근 실태를 파악하기 위함.
  • 정적 코드 분석만으로는 개발자가 숨겨 놓은 네트워크 호출을 찾기 어렵기 때문.

4.2.1. Test Infrastructure

  • 네트워크 구성: 실제 가정 환경과 유사하게 일반 공유기 아래에 주요 IoT 기기 4종(Google Chromecast, Amazon Alexa speaker, Philips Hue, Ikea Trådfri)을 연결했다. 이를 통해 앱들이 이들 기기와 통신을 시도하는지 관찰.
  • 분석 장비: Jailbreak된 아이폰과 Rooting된 픽셀폰을 사용하여 tcpdump라는 도구로 스마트폰에서 오가는 모든 네트워크 패킷을 직접 캡쳐 & 분석.
  • 정확성 확보: 분석된 트래픽이 OS의 백그라운드 동작이 아닌 앱에서 발생한 것임을 확인하기 위해, 일관되게 반복적으로 발생한느 경우에만 앱의 행위로 간주.

4.2.2. Automatic App Interaction

  • 분석 방식: 단순히 앱을 켜두는 것을 넘어, DFS 알고리즘을 이용해 자동으로 앱의 UI를 클릭하며 다양한 기능을 체계적으로 테스트했다.
  • 분석 단계:
    1. 초기 30초: 앱 실행 직후 사용자 조작 없이 발생하는 네트워크 접근(더 의심스러운 행위; more suspicious)을 탐지
    2. 이후 25단계 상호작용: 버튼 클릭 등 25번의 자동 조작을 통해 특정 기능 사용 시에만 발생하는 접근을 탐지한다.
  • 권한 처리: 분석의 일관성을 위해, 두 플랫폼 모두에서 앱이 요청하는 모든 permission을 사전에 허용했다. (iOS 로컬 네트워크 permission을 허용하지 않으면 트래픽 관찰 자체가 불가능)

4.2.3. Rationales and Bonjour Strings

  • 정적 분석 병행: iOS 앱의 경우, 앱 파일(Info.plist)을 직접 분석하여 개발자가 명시한 권한 요청 사유 문구(NSLocalNetworkUsageDescription)와 Bonjour 서비스 선언 목록을 추출하는 스크립트를 개발하여 추가로 분석.

4.3. Results

4.3.1. Local Network Accesses

Table 2

  • 접근 빈도: 분석 대상 중 iOS 앱 1.4%(152개), Android 앱 1.08%(117개)에서 로컬 네트워크 접근이 발견되었다.
  • Access Types
    • iOS는 애플의 생태계 기술인 Bonjour(mDNS)를 활용한 멀티캐스트(Multicast) 방식이 압도적으로 많았다(117개 앱).
    • Android는 Broadcast나 특정 IP 주소에 직접 통신하는 방식이 더 많았고, Multicast는 주로 미디어 장비 탐색용 SSDP 프로토콜을 사용했다.
  • Access Phases
    • 앱이 언제 로컬 네트워크에 접근하는지 추가로 분석했다.
    • Android 앱 75.21%, iOS 앱 65.13%로 사용자 상호작용 전에 이미 로컬 네트워크에 접근했다.
      • iOS 권한은 앱이 처음으로 로컬 네트워크에 접근할 때 이를 투명하게 만들기 때문에 이러한 차이에 영향을 미쳤을 수 있다.
    • 연구에서는 두 플랫폼 모두에서 접근하는 앱을 70개 발견했다.
      • 13개의 Android 앱(18.57%)은 상호작용 전에 접근했고, iOS 앱은 상호작용 후에만 접근했다.
      • 대조적으로, 5개의 iOS 앱(7.14%)은 열자마자 로컬 네트워크에 접근하는 반면, 그에 해당하는 Android 앱은 상호작용 후에만 접근했다.
      • 42개의 앱(60%)은 상호작용 없이 두 플랫폼 모두에서 접근했고, 10개의 앱(14.29%)은 상호작용 후에만 접근했다.
  • Case Studies
    • 로컬 네트워크에 접근하는 앱 수동 분류: IoT 기기용 companion 앱(112, 56.28%), 비디오 앱(17,8.54%), 이벤트용 앱(16, 8.04%)
    • Android에서 로컬 네트워크에 접근하는 적은 카테고리: 쇼핑 앱 2개, 데이팅 앱 1개, 암호화폐 지갑 1개
      • 이들을 수동 분석:
        • 4개 모두 Android 버전에서만 로컬 네트워크 접근을 관찰
        • 공통으로 Alibaba 라이브러리 보유
        • 앱이 처음 실행된 후 연결된 WiFi의 ARP 스캔을 수행. 스캔을 담당하는 코드는 암호화와 reflection으로 심하게 난독화
    • Among Us
      • 다른 플레이어를 찾기 위해 Universal Plug and Play(UPnP) 사용
      • 네트워크에서 UPnP 기기를 발견하면, 그것에 대한 더 많은 정보를 검색한다.
      • 본 연구의 테스트 네트워크에서는 이와 비슷한 것이 Philips Hue 브릿지와 Google Chromecast였고, 이들은 민감한 정보를 유출한다.
      • e.g., Philips Hue 브릿지는 model name, model number, serial number를 반환한다. 이 정보는 앱에 의해 광고와 추적에 사용될 수 있다.
  • Rationales and Bonjour Services
    • 본 연구의 데이터셋에서 permission rationales(권한 요청 사유)가 있는 727개(6.69%)의 앱과 Bonjour string을 선언한 586개(5.39%)의 앱을 발견했다.
    • 발견된 로컬 네트워크 권한을 트리거한 모든 iOS 앱 중에서, 98개(트리거된 권한의 61.25%) 앱은 권한 요청 사유를 선언했고, 62개(38.75%) 앱은 그렇지 않았다.
    • Bonjour mDNS 메시지를 보냈지만 Bonjour string을 선언하지 않은 27개의 앱을 발견했다.
      • 이를 수동으로 분석했고, 17개(62.96%) 앱은 내장된 Bonjour 메소드를 사용하지 않는 Google Cast용 라이브러리를 사용했다는 것을 발견했다.
      • 대신 이들은 커스텀 구현에 의존했고, iOS는 시스템 메서드에 대해서만 Bonjour string을 확인한다.
      • 따라서, 그 앱들은 이 확인을 우회했다.

4.3.2. Local Addresses Outside the Subnet

  • 연구에서는 연결된 로컬 서브넷 외부의 로컬 네트워크 주소에 접속을 시도하는 비슷한 수의 iOS 및 Android 앱을 발견했다. 총 23개(0.21%)의 iOS 앱과 22개(0.2%)의 Android 앱이 그러한 행동을 보였다.
  • 위와 같은 행동에 대한 다른 이유 발견:
    • 특정 하드코딩된 주소에서 해당 기기에 접속하려는 IoT companion 앱들이 존재했다.
    • 다른 앱에서는, 접속된 주소를 development artifacts(개발 잔여물)나 버그로 간주한다.
    • e.g., 스마트 도어락 및 감시 시스템에 속하는 Android 앱 Door Entry CLASSE300X가 /24 네트워크에 연결되었음에도 불구하고, /23 네트워크 공간의 ARP 스캔을 수행하는 것을 관찰.
      • 잘못된 네트워크 공간의 스캔은 네트워크 마스크를 계산할 때의 개발 버그 때문에 발생했다.

5. Permission Rationales

Table 3

  • permission의 기술적 측면과 앱의 로컬 네트워크 접근을 이해한 후, 본 연구에서는 로컬 네트워크 permission에 대한 정보에 입각한 결정을 내릴 수 있는 사용자의 능력을 알아본다.
  • 앱이 permission을 요청할 때, 사용자에게는 시스템이 생성한 설명과 개발자가 앱이 이 권한을 필요로 하는 이유를 설명하기 위해 설정할 수 있는 메시지로 구성된 요청 사유, rationale이 제시된다.
    • 개발자가 custom message를 제공하지 않으면 기본 메시지가 표시된다.
    • 이러한 메시지들은 대부분 사용자가 권한 부여 여부를 결정하기 전에 얻는 모든 정보이다.
    • 이러한 메시지의 내용을 조사하는 것은 사용자의 의사 결정 과정에 어떤 정보가 들어가는지 이해하는 데 도움이 된다.
  • 따라서, 요청 사유에 대한 내용 분석을 수행하여서 다음에 대한 답을 한다; RQ3: which concepts constitute the permission rationales?

5.1. Methodology

  • 4.2.3.에서 이미 설명한 것과 같이 데이터셋의 iOS 앱에서 요청 사유를 자동으로 추출했다.
  • 이 문자열을 필터링하여 독일어와 영어로 된 첫 번째 요청 사유만 포함시켰다.
  • 다음으로, 세 명의 연구자가 독립적으로 100개의 요청 사유 샘플을 코딩했다.
  • 대부분의 요청 사유는 단순한 구조를 따르며, 종종 유사한 구성을 사용한다.
  • 식별된 모든 개념은 메시지에 명시적으로 포함되어 있어, 데이터셋을 코딩하기 위해 키워드 기반 접근 방식을 사용할 수 있음을 의미한다.
    • 따라서 연구에서는 코드북의 각 코드에 대한 키워드 목록을 개발했다.
    • 요청 사유에 목록의 키워드 중 하나가 포함되어 있으면, 해당하는 코드를 자동으로 할당했다.
  • 코딩과 정제 과정을 반복하여 키워드 목록에 추가할 새로운 용어를 찾지 못하고, 의미 있는 내용이 없는 요청 사유만 코딩되지 않은 상태로 남을 때까지 진행했다.

5.2. Results

  • 데이터셋에서, 727개(6.69%)의 앱이 권한 요청 사유를 포함하고 있었다.

  • Local Network

    • 가장 두드러진 개념은 로컬 네트워크였다.
    • 요청 사유가 있는 앱의 81.02%가 어떠한 형태의 로컬 네트워크를 언급했다.
    • 요청 사유는 주로 local network 또는 약어인 LAN이라는 용어를 사용했고, 일부는 WiFi 또는 wireless LAN과 같이 무선 변형을 직접 언급했다.
    • 앱의 상당 부분인 348개(47.87%)는 your network 또는 your WiFi와 같이 your라는 단어를 포함하여 해당 네트워크의 소유권을 암시하는 용어를 사용했다.
    • 28개(3.85%)는 networks you use라는 문구를 사용했다.
    • 25개의 요청 사유(3.44%)는 물리적 근접성을 나타내는 용어를 사용했다.
      • around you, nearby와 같은 표현은 사용자의 휴대폰 가까이에 있는 장치가 어떻게든 permission의 영향을 받는다는 것을 암시한다.

  • Device Interaction

    • permission 요청 사유에 포함된 두 번째 주요 개념이다(539번, 74.14%)
      • TV, IoT 기기 또는 휴대폰과 같은 다른 기기와의 모든 종류의 통신 포함
    • 가장 흔한 사례는 discovering other devices(다른 기기 발견)과 casting video or audio(비디오 또는 오디오 전송)이었다.
    • 다른 기기를 발견하는 것이 permission request의 주된 이유로 제시된 경우, 구체적인 후속 상호작용이 설명되지 않은 경우도 자주 발견했다.

  • Niche Use Cases

    • 다른 기기에 대한 구체적인 언급 없이 다른 사용 사례를 언급하는 요청 사유를 식별했다.
      • 이러한 사용 사례 중 어느 것도 요청 사유의 5% 이상에 존재하지 않았다.
    • 가장 빈번한 것은 gaming(4.13%), 즉 다른 플레이어를 찾는 것이었다.
    • 앱은 3.30%는 permission이 부여되면 개선된 UX를 약속했다.
    • 본 연구에서 사용한 데이터셋의 4개 앱은 인터넷에 접속하기 위해 권한이 필요하다고 밝혔는데, 이는 iOS가 일반적으로 인터넷 접속을 제한하지 않기 때문에 정확하지 않다.
    • 3개의 요청 사유는 네트워크 품질 테스트를 권한 요구의 이유로 제시했다.

  • Network Knowledge

    • 22개 앱(3.03%)은 TCP 또는 VoIP와 같은 기술적 약어를 포함하고 있어 처리하는 데 약간의 네트워크 지식이 필요했다.
    • 제공된 텍스트를 살펴봤을 때, 이러한 메시지 중 11개와 다른 21개의 메시지가 development artifacts임이 명백해졌다.
    • 이 발견은 개발자들이 소프트웨어의 공개된 버전에서 이러한 메시지를 제거하는 데 실패했거나, 앱에 전용 디버깅 모드가 포함되어 있음을 시사한다.

6. Users’ Permission Comprehension

  • 사용자에게 제시되는 정보를 확인한 후, 연구에서는 다음 질문에 답해야 한다; RQ4: What is the user’s understanding of these concepts?
  • 정보에 입각한 결정을 내릴 수 있는 사용자의 능력을 확인하기 위해 관련 개념에 대한 사용자의 인식을 이해해야 한다.
  • 본 연구에서는 온라인 설문조사를 사용하여 permission에 대한 iOS 사용자의 지식을 조사하고 기본 기술에 대한 그들의 인식을 도출한다.

6.1. Methodology

  • iOS 사용자의 로컬 네트워크 권한에 대한 이해를 조사하기 위한 전제 조건으로, 올바른 이해에 중요한 개념들을 도출한다.

6.1.1. Concepts Important for Understanding

  • 연구에서는 전문가 브레인스토밍 세션을 통해 로컬 네트워크 permission의 기본 개념을 결정했다.
  • 다음과 같은 개념들을 도출
    • Boundaries: 네트워크의 토폴로지, 즉 어떤 장치가 동일한 로컬 네트워크에 속하고 어떤 장치가 그 밖에 있는지.
    • Transitivity: 모바일 기기가 장소를 이동함에 따라 로컬 네트워크가 변경될 수 있다. permission은 한 번 부여되면 모든 로컬 네트워크에 적용된다.
    • Proximity: 물리적으로 서로 가까이 있는 장치가 반드시 동일한 네트워크의 일부는 아니다.

6.1.2. Misconceptions

  • 일반적인 오해를 식별하기 위해 세 명의 연구자가 독립적으로 Google에서 *“local network permission”*이라는 키워드로 검색했다.
  • 관찰된 빈번한 인식은 앱이 Bluetooth를 사용하거나 WiFi를 통해 인터넷에 접속하기 위해 로컬 네트워크 권한이 필요하다는 것이었다.
  • 일부는 permission이 부여되면 앱이 WiFi 비밀번호를 얻을 수 있다고 생각했다.
  • 사람들은 권한을 거부하면 네트워크의 다른 장치가 자신의 휴대폰을 보지 못하게 할 수 있다고 표현했다.

6.1.3. Survey Design

  • Structure
    • 온라인 접속
    • 로컬 네트워크가 무엇인지? → 그렇다 답하면 설명하도록
    • 모든 참가자에 대한 로컬 네트워크 객관식 질문
      • 주어진 목록 중 어떤 사용 사례가 앱이 로컬 네트워크 권한을 요청해야 하는가?
    • 가상의 비디오 기반 소셜 미디어 앱이 처음 실행될 때 권한 요청 프롬프트를 표시하는 시나리오 제시(나머지 질문의 참고 자료로 사용)
    • 세 블록으로 나뉜 일련의 진술 제시(T/F & “I don’t know”)
      1. 참가자들이 자신의 집에 있는 상황 상상
      2. 사용자가 집을 떠나 길을 걷는 상황 상상
      3. 참가자들이 카페나 사무실에 앉아 있는 상황 상상
    • 참가자들의 기술 친숙도를 Affinity for Technology Interaction(ATI) 척도를 사용하여 측정 및 참가자 통계 정보 수집

6.1.4. Recruitment

  • 참가자 모집을 위해 Prolific을 선택
  • 최종적으로 Prolific에서 150명의 참가자를 대상으로 연구를 시작
  • 참가자에게 적용된 기준:
    1. 18세 이상
    2. iOS 기기 사용
    3. 현재 미국 거주
  • 추정 소요 시간 12분에 대해 2£ 보상을 제공

6.1.5 Data Analysis

  • 참가자들을 로컬 네트워크가 무엇인지 아는 그룹 vs. 모르는 그룹: “Do you know what a local network is?”
    • “Yes” - 개념을 간략하게 말로 설명.
      • 이 설명을 바탕으로 참가자들을 지식이 없는 그룹으로 재분배.
    • 그룹 간의 차이와 개념, 위협, 오해에 대한 답변을 연구하기 위해 T-test, test 수행

6.2. Results

Table 4

Table 5

6.2.1. Overview of Participants

  • 총 148명의 참가자
  • 31명(20.94%)은 로컬 네트워크가 무엇인지 모른다고 답했다.
  • 나머지 117명은 설명을 제공했다.
    • 71개의 응답을 정확한 것으로, 46개를 부정확한 응답을 분류
    • 총 77명(31+46)이 정확한 이해를 하지 못함
  • IT 배경이 있는 사람 중 58.33%를 정확한 이해를 가진 사람, 배경이 없는 사람의 경우 38.16%만이 정확한 이해를 가진 사람으로 분류
  • 검정은 그룹 간의 유의미한 차이를 보였다().

6.2.3. Concepts

  • transitivity 개념이 사용자가 이해하기 가장 어려운 개념
  • 참가자의 72.97%가 기본 질문에 올바르게 답했고, 다른 장소의 후속 질문에 올바르게 답한 사람은 23.85%, 50.46%는 그 중 적어도 하나를 잘못 답변했다.
  • 로컬 네트워크에 대한 이해가 있어도 transitivity 개념을 올바르게 답하는 능력은 향상되지 않았다.
  • 많은 참가자들이 network boundaries 개념과 관련된 proximity 개념을 이해했다.
  • 전반적으로, 참가자의 61.49%가 network boundaries에 대한 질문에 올바르게 답했고, 16.22%는 잘못 답했다.
  • 물리적 근접성에 있는 장치가 동일한 네트워크의 일부일 필요는 없다는 이해를 테스트가 위한 두 질문
    • 59.46%가 두 질문 모두에 올바르게 답했고,
    • 22.30%는 무엇을 답해야 할지 확신하지 못했으며,
    • 18.24%는 적어도 하나의 답변이 틀렸다.

6.2.4. Threats

  • 로컬 네트워크 접근으로 인한 네 가지 위협에 대한 질문
    1. 장치 노출
    2. 위치 추론
    3. 교차 사용자 추적
    4. 장치 식별
  • 긍정: 각 위협에 대해 참가자의 최소 절반이 어느 정보 인식을 보였다.
    • 대부분의 참가자는 방화벽으로 보호되는 장치도 네트워크 내에서는 여전히 접근 가능하다는 것을 알고 있었으며,
    • 56.76%가 해당 질문에 올바르게 답했고 29.73%는 확신하지 못했다.
    • 총 51.35%가 로컬 네트워크 내 장치 탐지에 대해 올바르게 응답할 수 있었다.
    • 50.68%는 로컬 네트워크 정보를 기반으로 사용자를 연결하여 교차 사용자 추적을 수행할 가능성을 올바르게 식별했고, 26.35%는 그것이 가능하지 않다고 생각했으며 나머지는 확신하지 못했다.
    • 참가자의 절반이 사용자의 위치를 추론하는 것에 대한 두 질문 모두에 올바르게 답했고, 25%는 적어도 하나의 답변이 틀렸다.

6.2.5. Misconceptions

  • 많은 참가자들이 기술적 배경과 로컬 네트워크에 대한 이해를 가지고 있음에도 불구하고, 오해가 흔하다는 것을 관찰했다.

  • 거의 모든 참가자(84.46%)가 권한에 대해 적어도 하나의 오해를 가지고 있었다.

  • 가장 흔한 오해:

    • 앱이 인터넷에 접속하기 위해 로컬 네트워크 접근이 필요하다는 것(59.46%)
    • 권한이 거부되면 휴대폰이 로컬 네트워크 내에서 보이지 않는다는 확신(57.43%)
    • 앱이 Bluetooth 통신을 위해 로컬 네트워크 권한이 필요하다는 생각(49.32%)
    • 권한이 WiFi 비밀번호를 검색할 수 있게 한다는 것(16.22%)
    • 로컬 네트워크 지식이 있는 그룹이 유의미하게 더 나은 성과를 보이지는 않는다

  • Rationales

    • 악의적인 앱은 오해를 이용하여 사용자를 속여 권한을 수락하게 한다.
    • 논문의 5장에서 4개의 앱이 요청 사유에 Internet을 언급했다.
    • e.g., 한 앱은 “This app requires an Internet connection to access your account data and vehicle features. Your local network will be used when cellular data is not available” 라고 명시하는데, 이는 사용자를 속여 권한을 부여하도록 할 수 있다.

7. Limitation and Future Work

  • 네트워크 접근을 위한 보호된 리소스의 내부 작동에 대해, 우리는 Apple의 개발자 문서에 의존한다. 이는 로컬 네트워크에 접근하는 모든 방법을 다루지 않을 수 있으며, 따라서 다른 우회 방법을 놓칠 수 있다.
  • 향후 연구는 TCC의 iOS 구현을 리버스 엔지니어링(reverse engineer)하여 내부 권한 처리를 연구할 수 있다.
  • 대규모 로컬 네트워크 접근 연구는 동적 분석(dynamic analysis)에 내재된 한계를 가진다. 앱은 분석되고 있다는 것을 감지하고 평소와 다르게 동작할 수 있다. 우리의 동적 상호작용기는 로그인이나 인증 후에만 사용 가능한 기능과 같이 로컬 네트워크 접근으로 이어지는 기능을 트리거하지 못할 수 있다. 따라서, 우리의 숫자는 하한선(a lower bound)이다.
  • AirPlay와 같은 Bonjour 서비스는 권한을 트리거하지 않아, 일부 기능이 왜 권한을 요구하지 않는지에 대해 사용자를 혼란스럽게 할 수 있다. 또한, AirPlay는 근처 장치를 발견하기 위해 Bluetooth를 사용할 수 있어, Bluetooth 오해에 영향을 미칠 수 있다.
    • 후속 연구는 오해를 더 깊이 연구하고 그것이 사용자의 권한 부여 결정에 미치는 영향을 심층적으로 연구할 수 있습니다.
  • 본 연구는 iOS 사용자에 초점을 맞췄다. Android 사용자의 로컬 네트워크 이해를 연구하는 것은 권한의 영향과 전반적인 효과성, 그리고 Android를 위한 유사한 권한을 설계하는 방법에 대한 추가적인 통찰력을 얻을 수 있습니다.
  • 마지막으로, 미국에 거주하는 사용자 샘플은 다양한 배경을 가진 다른 사용자 그룹에 대한 **일반화 가능성(generalizability)**을 저해할 수 있다. 향후 연구를 위한 한 가지 보완적인 방향은 iOS 및 Android 앱 스토어 리뷰의 자동화된 마이닝(automated mining)이다.

(생략)

9. Conclusion

  • 본 연구에서는 권한을 bypass 할 수 있는 두 개의 iOS 컴포넌트를 식별했으며, 복잡한 네트워크와 VPN**에 대한 보호가 불충분하다는 것을 확인했다.
  • 동적 분석을 통해, 우리는 권한이 앱이 로컬 네트워크에 접근하는 시점에 잠재적으로 영향을 미친다는 것을 보여주었다.
  • Android 앱보다 더 많은 iOS 앱이 로컬 네트워크에 접근하는 것을 발견했는데, 이는 Apple의 멀티캐스트 프로토콜인 Bonjour에 의해 야기된 것으로 보인다.
  • 더 나아가, 앱들이 service string을 선언하지 않고 Bonjour 메소드를 사용하여 그것들의 사용 요구사항을 우회하는 것을 발견했다.
  • 권한 요청 사유(permission rationales)에 대한 우리의 내용 분석(content analysis)을 통해, 대부분의 메시지를 이해하기 위해서는 로컬 네트워크가 무엇인지에 대한 이해가 필수적임을 보여준다. 이를 바탕으로, 우리는 권한에 대한 사용자의 이해, 로컬 네트워크 접근으로 인한 위협, 그리고 오해를 연구했다.
  • 긍정적으로, 우리는 거의 모든 참가자(83.11%)가 적어도 하나의 위협을 인지하고 있다는 것을 발견했다.
    • 그러나, 오해는 훨씬 더 널리 퍼져 있었으며(84.46%가 적어도 하나를 가짐), 이는 악의적인 앱이 사용자를 속여 권한을 부여하도록 돕는 데 사용될 수 있다.

Discussion

Graph View