Home

Title of the paper: iOS, Your OS, Everybody’s OS: Vetting and Analyzing Network Services of iOS Apps

To attack network service, an adversary can reach the victim easily and perform remote attack directly. Since NO man-in-the-middle (MITM), NO user interaction (0-click) is needed to perform such attack, network service attack is always considered to be more severer than others. Nowadays, discovering vulnerability in network service is a hot topic.

Inspired by previous work on vetting the security of network service a.k.a., "open port" of android app, we decide to study the security of network service of iOS app. For such study, we have to solve challenges of collecting iOS apps, collecting network service libraries and performing dynamic and static analysis on iOS apps.

Contributions of our study includes: 1) Efficient iOS app collection methodology. 2) Systematic characterization of network services of iOS apps. 3) New vulnerabilities identified through large scale analysis.

Findings of our study includes: 1) You are carrying a BYOD server at most time, for we surprisingly find over 40% iOS apps contains API `_bind`, which is used to turn an iOS device into a server. 2) A collection of vulnerable apps and third-party network service libraries are discovered. (Google issue ID: 109708840, Tencent issue IDs: 34162 and 23546, CVE-2019-14924, CVE-2019-14951, etc.)

Our study reveals that most network service are introduced by using third-party network service library and only a few of them are implemented from the scratch. The 1) vulnerable third-party network service library, 2) wrong configured third-party network service library, or 3) the buggy customized network service incur remote network service attack for end-user's device.

This site is a support for our work: iOS, Your OS, Everybody’s OS: Vetting and Analyzing Network Services of iOS Apps, all data, demo, source code and scripts related to our work are collected here.

Why iOS app provide network service

After studying 1,300 seed apps and deducing the intents of the developers, we reveal the scenario of the network services of iOS apps. There are universal intents on both iOS and Android, working as an endpoint of CDN for instance. Moreover, there are iOS specific network services, to bypass resource access control of iOS for example.

1. Helping end-users to manage their devices.

Although an iOS device end-user can manage his device via iTunes' client, backup and restoration phone contents, as well as the file sharing, some vendors provide light weight solution for this task. For example, in order to help users manage their devices, QQBrowser use CocoaHTTPServer to turn the device to a server. After a pairing process, users can manage their iOS devices through QQBrowser in desktop computer. For file sharing, VLC, Tex Writer use CocoaHTTPServer library to setup a website to share files between iOS devices and desktop computers.

2. Use other device to enhance the smartphone’s performance.

Suffered from small screen, weak stereo, out of date navigation system, there is demand for projecting the apps’ function to high-definition television, home audio system, or an in-vehicle infotainment (IVI) system. Google or Samsung deliver third-party libraries Google Cast or Smart View to enable smartphones to initiate and control playback of internet-streamed audio/video contents on a compatible device. Apps integrate these libraries will start network services on mobile phone. For example, Google Cast library will start network service on port 5353, 2345, 47777, etc. for User Datagram Protocol (UDP) service. To connect with an IVI system, app on smartphone makes the device as a server and waits for connection from the IVI system. Message from the IVI side to the app is relayed over USB, WiFi or Bluetooth.

3. Working as a node of content distribution networks (CDN).

The peer-to-peer or peer-to-server&peer CDNs structure makes the media player app as a node. As a consumer of network resources, the app provides network resources in turn, which makes the iOS device to be a server. For example, the Amazon Prime Video app implements HTTP Live Streaming (also known as HLS) in peer-to-peer CDNs structure for media streaming sharing. To provide resources, the app starts web service on port 80 via GCDWebServer library. Apps in the same LAN can access the network media resources for better quality of service and experience.

4. Accommodating to offline-mode.

Some developers build their apps on top of dynamic resources. For example, developers use WebView to add web contents to the apps or use database for data processing. In order to accommodate to offline-mode, developers synchronize resources when the apps are online and use local resources when the apps are running in offline-mode. By hosting a server in local devices, the apps can work well in offline-mode by resorting to the local network resource providers.

5. Bypassing resource access control of iOS.

In practice, we find that there are various limitation for a developer to load local resource to their apps. For example, the same-origin policy in iOS 8 prohibits the access for local files when using file:// protocol, this makes some apps depending on local resource can not work well. In order to solve this problem, some developers embedded a server in their code as to access the resource via http:// protocol instead of the file:// protocol.

6. For debugging.

To facilitate app development, developers make their apps as a server to provide the collected runtime information. For example, the SmartDeviceLink library which is used to connect in-vehicle infotainment systems with smartphone apps will start a service to write log information to the connected client.

We category the network service by intent but not the specification (e.g., DIAL) or protocol (e.g., UPnP). More minority of intent is not list here (e.g., wangxin.taobao library can be used to set UUID of current device remotely).